The present disclosure relates generally to file access, and, in particular, to coordinating file system access.
In a general purpose computer system environment, applications may access data stored on disks drives via a set of operating system services including a file system. A file system includes a set of files on a disk and the program tools for maintaining the set of files. File systems that control the physical representation of objects, such directories and files, are known as physical file systems (PFSs).
Also included in a general purpose computer system environment is a kernel that performs basic functions, such as allocating hardware. The kernel is the central part in most computer operating systems and manages the system's resources and the communication between hardware and software components. As a basic component of an operating system, a kernel provides abstraction layers for hardware that allow hardware and software to communicate.
A logical file system (LFS) is the level of the file system at which users can request file operations using a system call. The LFS provides the kernel with a consistent view of what may be multiple physical file systems and multiple file system implementations.
A consistent view of file system implementation is made possible by a virtual file system (VFS). This virtual file system is an abstraction of a physical file system implementation. It provides a consistent interface to multiple file systems, both local and remote. The interface allows the LFS code in the kernel to operate without regard to the type of file system being accessed.
Each time a file is opened or made accessible, the file system creates a data structure, known as a “vnode”, which is chained to the VFS. A vnode is an abstract representation of an active file and provides a generic way to operate on the real file it represents, regardless of the file system it resides on.
In a distributed computing environment, a number of computing systems can be interconnected by way of a communication network and can share files by way of a distributed file system. An example of a distributed computing system is a server-client system in which one or more remote client devices are serviced by one or more server devices. The server devices control access by the client devices to disks containing file system data.
A file exporter running on the server provides data to remote clients (which are connected to it). Access for locally exported file system data may be referred to as local access, while access for remotely exported file system data may be referred to as remote access. When a file server obtains data to fulfill a remote client's request for data, a cache manager process in the kernel of the file server caches a copy of the data. As long as the data does not change, the locally cached copy remains available to the remote client. A new copy is retrieved only when another process changes the data.
In contrast to remote clients, which are external to but connected to the distributed file system, there are also applications which are part the distributed file system. Data requests by applications are handled differently from requests from remote clients.
To understand how data requests from applications are handled, consider a sysplex, which is a system of mainframes acting together as a distributed file system. In a traditional sysplex, an application request is received by the LFS, and the LFS forwards the request for a remotely owned exported file system to the PFS of the owning file server. In this type of system, a server-type file exporter supplies on the server a program “G” to control local access to its exported file systems. This program is used to synchronize file changes and is invoked by the LFS. The LFS does not distinguish between types of file systems, whether local, remote, or strictly logical. The “G” program is invoked by the LFS before and after every vnode operation, i.e., each time a file is opened or made accessible, and a vnode is created. The coordination of file changes before and after every vnode operation is performed by getting and revoking tokens using the G program. The file exporter on each file server distributes tokens to allow access to data from the file server on behalf of remote clients or to allow access to PFS data by the LFS. The file exporter uses tokens to manage access to data and metadata. The tokens guarantee that remote clients and applications accessing the same data as the remote clients are provided with the most recent version of the data and that multiple clients are not accessing the same data in a conflicting manner.
As for remote clients, when a remote client wishes to access or change a file or directory that is managed by the file exporter, it first requests the appropriate tokens for the data from the file exporter. The file exporter's response to the client's request depends on the data the client wants to manipulate, the operation the client wants to perform on the data, and whether any other clients currently have tokens for the data.
If neither the LFS nor other clients have tokens for the data, the file exporter can issue the remote client the appropriate tokens. If outstanding tokens for the data exist, the file exporter can grant the request (if no conflicts arise between the request and the outstanding tokens), revoke the existing tokens to grant the request, or consider the request pending until it can grant it. In some cases, the file exporter simply refuses to grant the request. If the file exporter gives the client the necessary tokens, the client in turn can access the data from the file exporter in the fashion requested.
In a traditional sysplex, a file server only exports the file systems owned by the sysplex it is running on, i.e., the file system to which it has direct access to. In this type of system, a set of, e.g., z/OS systems communicate and cooperate with each other, through certain multisystem hardware and software components, to process user workloads. When the G program gets invoked on the local system, it communicates with the file server to coordinate the access by the LFS and remote clients.
When the PFS runs as sysplex-aware, i.e., the PFS allows a file system to be locally accessed on all members in a sysplex, this model breaks down because the LFS does not forward the file access requests for remotely owned file systems to the file server that owns the export for the file system, i.e., the file server that has direct access to the file system and is responsible for coordinating access to the file system. Therefore, the G program is not invoked, and the file exporter has no way to know when data changes or when to flush/update a cache. Instead, the PFS handles the request, whether local or remote, and performs its own caching. Because access to a remotely owned file system is not effectively coordinated, the file exporter's cached data may be inaccurate.
There is thus a need to improve the existing distributed file system access model to provide a file exporter with the ability to export a locally owned file system and a remotely owned file system and still maintain cache consistency.